自動のAPI分析・可視化でAPIモニタリングが捗る!F5の新SaaS「Distributed Cloud WAAP」を触ってみた〜APIセキュリティ編〜

自動のAPI分析・可視化でAPIモニタリングが捗る!F5の新SaaS「Distributed Cloud WAAP」を触ってみた〜APIセキュリティ編〜

APIへのリクエストモニタリングが捗りまくりです。
Clock Icon2022.08.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

みなさん、APIへのリクエストモニタリングってどうやってますか?面倒臭くないですか?

まずはこの図を見てください。

今回私が検証したサービスを使えば、リクエストが来たAPIエンドポイントをこんな感じに自動で分析・可視化してくれるんです!!自動でこんな樹形図が作れるって便利じゃないですか?

ということで本記事では、F5社が2022年に提供を開始した新型SaaSの「Distributed Cloud WAAP(XC WAAP)」を触ってみたので、XC WAAPの概要と実際に触ってみた一部機能をご紹介します。

ざっくりまとめ

  • WAAPとは「Web Application and API Protection」の略
    • XC WAAPはF5社が2022年から提供を開始したSaaS型のセキュリティソリューション
  • XC WAAPには主に以下の4つの機能が含まれる
    • WAF
    • APIセキュリティ
    • Bot Defense
    • DDoS攻撃対策
  • 本記事ではAPIセキュリティ機能をご紹介
    • API Discovery
    • APIエンドポイントへのアクセス制御

F5 Distributed Cloud WAAP(XC WAAP) とは

概要

XC WAAPの前に「Distributed Cloud Services(XC Services)」という2022年2月にF5社が発表したサービスについて説明します。XC Servicesとは、セキュリティやマルチクラウドネットワーキング、エッジベースコンピューティングのソリューションをSaaSとしてまとめて提供することが出来るプラットフォームです。これら3つのソリューションを1つのコンソール上から管理・運用することが出来るようになっています。

XC Servicesの1つとして「XC WAAP」が存在します。WAAPは「Web Application and API Protection」の略称です。

XC WAAPの主な機能は以下の4つです。

  • WAF
  • APIセキュリティ
  • Bot Defense
  • DDoS攻撃対策

XC WAAPではこれらの機能全てを1つのダッシュボード上から管理・運用出来るようになっています。下記画面の「すぐに試す」ボタンよりXC WAAPの導入デモを見ることが出来ます。実際のダッシュボードも表示されるため操作のイメージがしやすいかと思います。

XC WAAPのダッシュボードイメージ↓

また、下図はXC Servicesで提供されるサービスがまとめられた図ですが、水色部分の「WAF」、「Bot Defense」、「DDoS」、「API Sec」がXC WAAPに相当します。

引用元: F5、WebアプリケーションとAPI向けの包括的なSaaS型セキュリティを発表 | F5

それでは、XC WAAPが提供するそれぞれの機能について見ていきます。

WAF

Web Application Firewall | F5 Distributed Cloud Services

WAFはXC WAAPの中でもメインの機能だと私は思っています。XC WAAPのコンソール上で作成したロードバランサー(LB)に「App Firewall」と呼ばれるオブジェクトをアタッチすることで、SQLインジェクションやXSSのような攻撃を防ぐことが出来ます。この「App Firewall」に設定するセキュリティポリシーなどはデフォルトで用意されているものもあり、セレクトボックスで適当なものを選択するだけで簡単に「App Firewall」を作成することが出来ます。

APIセキュリティ

Distributed Cloud API Security l F5

APIセキュリティの機能には大きく分けて「API Discovery」と「APIエンドポイントへのアクセス制御」があります。詳しくは後述しますが、このうちの「API Discovery」という機能はアプリケーションのAPIを自動で分析・可視化してくれるという機能で、分析されたAPIの定義をSwagger形式でエクスポートすることも可能です。また分析されたAPIに対して防御ルールを設定することも出来ます。

Bot Defense

F5 Distributed Cloud Bot Defense | F5

JavaScriptやAPI呼び出しを使用してテレメトリを収集することで、クレデンシャルスタッフィングやアカウントの乗っ取りなど、botを利用した幅広い攻撃からアプリケーションを保護する機能です。こちらもLBに統合されているため、手軽に導入することが出来ます。

DDoS攻撃対策

L3およびL7 DDoS攻撃の抑制 | F5

L3~L4,およびL7をDDoS攻撃から防御出来る機能です。ユーザーが特定のクライアントを設定する防御方法に加え、AI/ML機能によるインテリジェントな保護機能も使用することが出来ます。

料金

XC WAAPというよりはXC Servicesの料金体系になりますが、無料のプランも含めて4つのプランが用意されています。

プラン名 料金
無料 $0 /月
個人 $25 /月
チーム $200 /月
組織 応相談

各プランに応じて使用可能な機能は異なります。詳しくは以下をご参照ください。

F5 Distributed Cloud Servicesの価格 | F5

また、XC WAAPはAWS Marketplaceから簡単にサブスクライブ(契約)することが可能です。現在は年間の定額サブスクライブのみが提供されています。

AWS Marketplace - F5 Distributed Cloud Services

実際に触ってみた〜APIセキュリティ編〜

今回はそんなXC WAAPの「APIセキュリティ」の機能を触ってみたのでご紹介します。

用意した環境

XC WAAPではまずLBを作成し、その後段に防御したいアプリケーションを配置します。

今回は後段のアプリケーションとして、OWASPの「DVSA」という"やられサーバレスアプリ"を使用しました。DVSAについては以下を参照ください。

OWASP DVSA | OWASP Foundation

github: https://github.com/OWASP/DVSA

構成図はこんな感じです。DVSAの構成は正確じゃないですが、API Gatewayの後段で各APIごとのLambdaが動いているイメージです。DVSAの各APIにユーザーはXC WAAPのLBを経由してアクセスします。

XC WAAPのLB作成手順については今回省略します。

手順の詳細は公式ドキュメントが公開されていますので、下記をご参照ください。下記ドキュメントのStep2までがLB作成の手順に該当します。

Web App Security | Performance | F5 Distributed Cloud Tech Docs

ちなみにWAFなどの機能を導入する場合にも、基本的にはこのLBに各ルールやポリシーを設定していくことになります。

モニタリング - API Discoveryの設定

API Discoveryとは、アプリケーションが持つAPIエンドポイントへのアクセスをXC WAAPが分析・学習し、有効なAPIエンドポイントと各APIエンドポイントへのリクエスト流量を可視化してくれる機能です。下記が公式のドキュメントです。

API Endpoint - Discovery | Control | F5 Distributed Cloud Tech Docs

本機能はLBの設定 Security Configuration から有効化することで利用可能となります。まずは下図赤枠部の Show Advanced Fields が表示されるようにスイッチしてください。

Security Configuration の最下部に API Discovery/DDoS Detection/Malicious User Detection の設定があります。そこで API DiscoveryEnable にしてください。

これだけで設定は完了です。簡単ですね。

モニタリング - API Discoveryを使ったモニタリング

この状態でアプリケーションのAPIエンドポイントへアクセスがあり、そのAPIエンドポイントがクライアントへ200レスポンスを返すことで、XC WAAPはそのAPIを"有効なAPIエンドポイント"と判断します。私の体感では、APIエンドポイントへのリクエストが発生してから約1時間半ほどでXC WAAPのダッシュボードの API Endpoints に反映されます。

検出されたAPIエンドポイント数が少ないので少し見栄えは悪いですが、実際にAPIエンドポイントを自動検出した際のダッシュボードは下図です。リクエスト量に応じて伸びている線の太さが異なる仕様になっています。そして右上の Download Swagger からは表示されているAPIエンドポイントのSwaggerをダウンロード出来ます。

また、そのAPIエンドポイントにマウスカーソルを重ねるとPathやメソッド、リクエスト量の割合などが表示されます。

APIエンドポイントをクリックすると、APIエンドポイントの詳細画面が右側にポップアップします。

ここではエラーレートやレスポンスレートなどの各種メトリクスをグラフで参照することが出来ます。

ちなみに各メトリクスのグラフをクリックすると、メトリクスの詳細画面に遷移します。

また、APIエンドポイントのダッシュボードは上で紹介した樹形図のグラフ以外に、下図赤枠部の Table タブをクリックすることでテーブル形式に切り替えることが出来ます。

テーブル形式に切り替えると下図のようになります。ここでも先ほど詳細画面で見た各種メトリクスが表示されていますね。

また、このテーブルはカラムを好きな場所に移動させることが出来るため、下図のようにメトリクスグラフを左の方に寄せたり、ユーザの好みに合わせることが可能です。(※下図は公式ドキュメントより引用)

引用元: Monitor your Service | F5 Distributed Cloud Tech Docs

アクセス制御 - APIエンドポイントへのアクセス制御機能

それでは、次はAPIエンドポイントへのアクセス制御機能についてです。

一口に「APIエンドポイントへのアクセス制御機能」と書いていますが、実際には以下の3つの設定方法があります。

  • API Protect
    • APIエンドポイントを指定して設定する方法
    • Swaggerを利用して作成したAPI Groupで設定する方法
  • Swaggerを利用して作成したAPI GroupでService Policyを設定する方法

今回は3つ目の「Swaggerを利用したAPI Groupによる通信制御」が便利で手軽だったのでご紹介します。この機能はSwaggerに定義されたAPI群をターゲットとし、それらに対するクライアントからのアクセス制御をまとめて設定出来るという機能です。この機能を使うことで、クライアントに見せても良いAPIエンドポイント、見せたくないエンドポイントをまとめて管理することが出来ます。

アクセス制御 - API Definitionの作成とアタッチ

XC WAAPではSwaggerを読み込ませることで「API Definition」を作成することが出来ます。

まずはSwaggerをインポートするため、 Manage > Files > Swagger Files よりSwaggerの一覧画面に遷移します。

Add Item から作成画面に遷移します。Name に任意の文字列を入力し、Swaggerファイルをアップロードしてください。最後に Save and Exit で保存します。

次にこのSwaggerをAPI Definitionにアタッチします。Manage > API Management > API Definition からAPI Definitionの一覧画面にに遷移してください。

こちらも Name に任意の文字列を入力し、Swagger Specs でアタッチするSwaggerを選択します。最後に Save and Exit で保存します。

API Definitionを作ったら、LBの編集画面に移動し、作成したAPI Definitionをアタッチします。

アクセス制御 - Service Policiesの作成

LBをアタッチしたら、LBの設定よりService Policiesを作成/設定します。下図赤枠部のように Apply Specified Service Policies を選択し、Edit Configuration をクリックすることでService Policiesの一覧画面に遷移します。

Policiesと複数形になっていることからも分かるのですが、Service Policyは複数設定することが出来ます。

それでは下図赤枠部の Create new Service PolicyからService Policyを作成していきましょう。

下図はService Policyの作成画面です。Name を入力後、下図赤枠部よりRulesを設定します。

選択出来るルールは下記の5つです。

  • Allowed Sources
  • Denied Sources
  • Custom Rule List
  • Allow All Requests
  • Deny All Request

Allowed/Denied All Requestはその名の通り全許容/全拒否です。

Allowed/Denied Sourcesでは下図のように「IPアドレス」や「BGP ASN」、「国」でリクエスト元を制御することが出来ます。

上図下部にある Default Action ではここでの設定に合致しないリクエスト元へのアクションを下図のように Next Policy/Allow/Deny の中から選択することが出来ます。

アクセス制御 - Custom Rule Listの作成

ただし、今回はCustom Rule Listを作成していきます。Custom Rule Listを選択し、 Configure よりCustom Rule List画面へ遷移します。

下図がCustom Rule List画面です。

ここでは複数のルールを作成/設定することが出来るのですが、各ルールの優先順位はここでの Order に依存するので注意しましょう。数字が若いものの優先度が最も高いようです。

それでは Add Item よりルール作成画面に遷移します。Nameを入力し、下図赤枠部の Configure をクリックします。

下図がルールの設定画面です。下図赤枠部からも分かるように、ルールは非常に細かく設定出来ます。

ここでは主に設定するActionとClientsについてご紹介します。

まずはAction。下図のように通常時のActionだけでなく、Botに対するアクションや悪意のあるユーザーに対するアクションなどを指定出来ます。

  • Action
  • Select App Firewall Action Type
  • Select Bot Action Type
  • Malicious User Migration Action
  • IP Reputation Action

次にClients。下図のようにClientはIPやASNなどで制御することが可能です。

  • Client Selection
  • Sources IPv4 Match
  • Source ASN Match
  • TLS Fingerprint Matcher

他にも様々な項目でリクエストを制御することが出来ます。下記はその一例です。

  • リクエストのHTTPメソッド
  • リクエストのHTTPヘッダー
  • リクエストのbody
  • リクエストのCookie

アクセス制御 - 実際にリクエストを防御してみた

それでは拒否設定を行ったAPIエンドポイントに対して実際にリクエストを投げてみましょう。

ルールでアクセスを拒否したAPIエンドポイントにアクセスするとちゃんとアクセスが防御され、このような画面が表示されました。

ちなみにアクセスが拒否されてエラーが発生すると、本ブログのモニタリングパートで紹介したエラーレートのメトリクスにも反映されます。

この画面に表示されている Your support ID でXC WAAPのダッシュボードを検索すると対象のリクエスト内容を見ることが出来ます。

リクエスト内容はJSON形式でも確認することが出来ます。下記は一部*(アスタリスク)でマスクしています。下の矢印部分をクリックしていただけると展開します。

リクエスト内容(JSON)
{
  "country": "JP",
  "kubernetes": {},
  "app_type": "ves-io-default-demo-api-classmethod-lb",
  "browser_type": "Chrome",
  "device_type": "Mac",
  "req_id": "2c98909e-6121-42bf-884f-ad5e93231dc5",
  "path": "/",
  "hostname": "master-5",
  "original_authority": "*****.classmethod.info",
  "rtt_upstream_seconds": "0.0",
  "src_instance": "JP",
  "req_headers": "null",
  "tenant": "classmethod-ldinsvrg",
  "longitude": "130.410900",
  "app": "obelix",
  "rtt_downstream_seconds": "0.011000",
  "policy_hits": {
    "policy_hits": [
      {
        "result": "deny",
        "policy_set": "ves-io-http-loadbalancer-network-security-demo-api-classmethod-lb",
        "malicious_user_mitigate_action": "MUM_NONE",
        "policy_namespace": "default",
        "policy_rule": "ves-io-service-policy-dvsa-service-policy-dvsa-sp-rule2",
        "policy": "dvsa-service-policy",
        "rate_limiter_action": "none"
      }
    ]
  },
  "method": "GET",
  "time_to_last_downstream_tx_byte": 0.002131393,
  "source_type": "http",
  "dst_instance": "NOT-APPLICABLE",
  "vh_type": "HTTP-LOAD-BALANCER",
  "x_forwarded_for": "***.***.***.***",
  "duration_with_no_data_tx_delay": "0.0",
  "rsp_size": "419",
  "api_endpoint": "UNKNOWN",
  "authority": "*****.classmethod.info",
  "region": "40",
  "time_to_first_downstream_tx_byte": 0.002121344,
  "rsp_code_class": "4xx",
  "rsp_code_details": "ext_authz_denied",
  "time_to_last_upstream_rx_byte": 0,
  "dst": "NOT-APPLICABLE",
  "scheme": "https",
  "city": "*****",
  "dst_site": "NOT-APPLICABLE",
  "latitude": "33.618400",
  "messageid": "dea91c9a-beed-4561-67af-ab4112426b1f",
  "tls_version": "TLSv1_3",
  "connection_state": "CLOSED",
  "dst_ip": "NOT-APPLICABLE",
  "network": "***.***.***.***",
  "src_site": "os1-osa",
  "terminated_time": "2022-08-05T03:28:17.384638102Z",
  "duration_with_data_tx_delay": "0.0",
  "src_ip": "***.***.***.***",
  "connected_time": "2022-08-05T03:28:17.381618936Z",
  "stream": "svcfw",
  "tls_cipher_suite": "TLSv1_3/TLS_AES_128_GCM_SHA256",
  "original_path": "/",
  "req_size": "867",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36",
  "severity": "info",
  "cluster_name": "os1-osa-int-ves-io",
  "tls_fingerprint": "6351a79c0fa176d8764f5712c1f02895",
  "src": "N:public",
  "time_to_first_upstream_rx_byte": 0,
  "rsp_code": "403",
  "time_to_first_upstream_tx_byte": 0,
  "sni": "*****.classmethod.info",
  "src_port": "49471",
  "site": "os1-osa",
  "@timestamp": "2022-08-05T03:28:17.601320Z",
  "sample_rate": "0.990000",
  "time_to_last_upstream_tx_byte": 0,
  "dst_port": "UNKNOWN",
  "namespace": "default",
  "req_path": "/",
  "time": "2022-08-05T03:28:17.601Z",
  "asn": "Softbank BB Corp.(17676)",
  "user": "IP-***.***.***.***",
  "vh_name": "ves-io-http-loadbalancer-demo-api-classmethod-lb",
  "node_id": "envoy_2",
  "proxy_type": "http",
  "total_duration_seconds": 0.003
}

より詳細な手順は以下の公式ドキュメントをご参照ください。

Import Swagger to Define and Control API Groups | F5 Distributed Cloud Tech Docs

まとめ

私が感じたXC WAAPのメリットは「導入・管理の手軽さ」です。XC Servicesの思想である「全ての機能を1つのコンソールで運用・管理出来る」からも分かるように、XC WAAPのメリットも「全ての機能を1つのダッシュボードで運用・管理出来る」ことにあると思っています。XC WAAPは作成したLBに4つの機能に関連するルールやポリシーをアタッチしていくという性質上、最初は設定項目が多く煩わしく感じるかもしれませんが、一度作成したLBの設定を少し変えるだけで新機能を導入することが出来る点は非常に楽です。

気になった方は公式が用意しているデモを見られてはいかがでしょうか。

なお、本記事内では参考資料として主に英語版の公式ドキュメントをご紹介しましたが、XC WAAPの公式導入ドキュメントは日本語版(↓)も用意されています。下記ドキュメントも是非ご活用ください。

日本語版: F5 Labs - Index — F5 DCS WAAP Lab ドキュメント

XC WAAPの他の3つの機能についても近いうちにブログ化したいと思っています。

以上、べこみんでした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.